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ABSTRACT 

Presented is a design tool and process that connects several disciplines which are needed in the complex 
and integrated design of high performance reusable single stage to orbit (SSTO) vehicles. Every system is 
linked to all other systems, as is the case with SSTO vehicles with air breathing propulsion, which is 
currently being studied by the National Aeronautics and Space Administration (NTASA). In particular, the 
thermal protection system (TPS) is linked directly to almost every major system. The propulsion system 
pushes the vehicle to velocities on the order of 15 times the speed of sound in the atmosphere before pulling 
up to go to orbit which results in high temperatures on the external surfaces of the vehicle. Thermal 
protection systems to maintain the structural integrity of the vehicle must be able to mitigate the heat 
transfer to the structure and be lightweight. Herein lies the interdependency, in that as the vehicle’s speed 
increases, the TPS requirements are increased. And as TPS masses increase the effect on the propulsion 
system and all other systems is compounded. To adequately calculate the TPS mass of this type of vehicle 
several engineering disciplines and analytical tools must be used preferably in an environment that data is 
easily transferred and multiple iterations are easily facilitated. 


INTRODUCTION 

Developing the next generation of launch vehicles is a primary focus of the National Aeronautics and Space 
Administration (NASA). Several concepts have been proposed, many of which are fully reusable single 
stage to orbit (SSTO) vehicles. Lowering the cost of placing a payload into orbit drives this idea of a fully 
reusable vehicle. 

Analysis of these concepts is essential to determining which to carry forward into more detail design. 
According to Malone [1] in the current development process, 90% of the cost is committed in the first 10% 
of the development cycle. Thus, more design knowledge is needed in the design process to minimize 
changes. Also, the fidelity of the analyses is critical due to the strong interaction between each of the 
systems (Figure 1). This interaction is most notable in the SSTO concepts that involve air-breathing 
propulsion. In these concepts the thermal protection system (TPS) is a critical system. The TPS must 
protect the air frame structure of a vehicle which flies at 15 to 20 times the speed of sound in the 
atmosphere before the vehicle pulls up and goes into orbit. The TPS mass affects the mass of the vehicle 
which affects the propulsion system, the vehicle’s ascent trajectory, structure, aerosurfaces and other vehicle 
subsystems. The TPS can not just be added to vehicle but must be an integral part of the vehicle’s mission 
scenario definition. 
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Figure 1. Interaction of Vehicle Systems 


THERMAL ANALYSIS 

Several engineering disciplines are involved in vehicle analysis and design. This work will focus on the 
thermal protection system (TPS) analysis. Directly involved in TPS sizing are trajectory analysis and 
aerothermal heating analysis. To begin assessing the TPS mass requirements for a vehicle the trajectory 
analyst generates a trajectory that delivers the required payload to the specified orbit. Similarly the analyst 
calculates the trajectory required for a vehicle’s reentry from orbit. Next the aerothermal analyst calculates 
the convective heating rates on defined "body points” of the vehicle. TPS materials are selected based on 
the surface temperatures due to the heating on each defined surface. Finally the thermal analyst calculates 
the thickness of the TPS material and derives a mass. This process is iterated as often as necessary (time 
allowing) to achieve an optimum design. 


TOOLS 

Several disciplines (on different computing platforms and maybe even in different locations) use tools 
specific to their disciplines to provide input to the analysis process. The Program to Optimize Simulated 
Trajectories (POST) is used to calculate trajectories and vehicle ascent and reentry performance. The 
output of this code is a single large text file containing the numerical results for the run. The Miniature 
Version of the JA70 Aerodynamic Heating Computer Program (MINIVER) is used to calculate aerothermal 
heating. Its output also is a large set of data containing various information relative to understanding the 
heating environment of a launch vehicle. The program Systems Improved Numerical Differencing Analyzer 
(SINDA) is used to calculate the TPS thickness at each body point. It is a numerical solver used to 
calculate the temperatures of a thermal network of nodes set-up by the user. All of these programs are 
UNIX based although there are personal computer (PC) versions of SINDA. Other tools used are text 
editors and spread sheet programs used on desktop PC’s. 

PROCESS 


The problem with the process described is that those codes often reside on different computing platforms, 
and have output formats that are not compatible with the data input format required by other tools. Figure 2 
shows the process used in the Preliminary Design Office at NASA Marshall Space Flight Center. The 
vehicle’s ascent or reentry trajectory is generated using POST. Data specifically needed for input into the 
aeroheating model is extracted and passed via e-mail or by hand to the aeroheating analyst. The 
aerothermal heating analyst receives this data and uses a spreadsheet program to remove any unnecessary 
data points. Once this is completed the data is formatted (in the spreadsheet) and transferred from the PC to 
a UNIX based machine using a File Transfer Protocol (FTP) program. This part of the process is important 
since 
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Figure 2. Analysis Process 

the aeroheating program, MINIVER, only accepts 50 trajectory points. The data is further thinned using a 
computer program THINDATA on the UNIX machine that also formats the trajectory data to be used in the 
MINIVER model. This thinned trajectory' file is now transferred to the aeroheating analysts via e-mail or 
by hand. The aerothermal analysts inputs the geometry of the vehicle and the heat transfer options that will 
be used to calculate the convective heat rates on the defined number of areas of the vehicle, known as body 
points. The properly formatted trajectory data is added to the MINIVER input file, and the analyst then 
executes the program. The program generates much useful information, including the surface temperature, 
the convective heating rates, and pressure all as a function of time. The thennal analyst only needs the 
convective heating rate data for his SINDA model of the TPS material at each body point. The temperature 
data is desired because the temperature of the surface helps the thermal analyst select the TPS material to 
use at each body point. With these time varying heat rates the thennal analyst calculates the thickness of the 
TPS material. These heat rates are added into the SINDA models of each of the body points as defined 
earlier in the analysis. The SINDA models are now used to calculate the insulation thickness at each body 
point that is required to maintain the structure below its maximum temperature limits. These material 
thicknesses are then transferred back to the PC using the FTP program where a spreadsheet is used to 
compile the data. Using these thicknesses and the material density, the spreadsheet calculates the mass of 
TPS for each body point and sums all of the body point masses into a total vehicle mass. Further iterations 
of the complete process may be necessary because the TPS mass may be lowered by altering the trajectory 
to produce a lower total integrated heat load, or a different TPS material may be used that may be superior. 
If the vehicle moldline is changed, additional runs in trajectory and TPS process are required. 

Described in the previous paragraph is what Acton [2] has labeled a loosely integrated analysis. This 
methodology relies heavily on legacy codes and provides very little electronics integration. A goal of this 
effort is to produce what Acton [2] calls a tightly integrated analysis. In this framework the engineers still 
use the codes with which they are familiar, but these codes are linked or have interfaces between them such 
that data is easily exchanged between them. Described in the following paragraphs is a tightly integrated 
analysis tool called RECIPE®. 
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A COLLABORATIVE TOOL 


Collaboration between these disciplines is essential to adequately size the TPS for this type of vehicle. To 
increase the fidelity of the models and reduce cycle time for design the vehicle, there must be better 
interaction and exchanging of data. The development of a tool that interfaces with all of the tools and 
provides the output in the format necessary to be used by the other codes is desired. This tool would enable 
the usage of legacy tools such as SIND A, MINIVER, and POST. These codes are well understood by 
engineers and have become standards in the industry. That is important when trying to establish a very 
cohesive collaborative environment. This tool would also have to be cross-platform, meaning that it would 
be usable on and can transfer data between UNIX-based, PC, and Macintosh machines. This is again 
essential because all engineers have different computing platforms and tools that they use in their analysis. 

A solution to the aforementioned problem is RECIPE ^ . This software tool is a cross-platform application 
capable of hosting a number of engineers and designers across the Internet for distributed and collaborative 
engineering environments. It provides an interface between the engineering tools of a particular discipline 
and the other tools that need the data that it provides. The data is provided in the input format required by 
the designated receiving tool(s). The program allows the user to select from a suite of stand-alone programs 
that would be used for the desired analysis. For example, in the case of the TPS analysis described above, 
the users may choose POST as the trajectory analysis tool. But, if any other trajectory programs have been 
integrated into to the suite of programs, the user may choose it. Once he has executed his program and is 
satisfied with his results he can publish the data to be used by the analyst who is producing the aerothermal 
results. 

According to Stanley [3] the user interfaces for the RECIPE 1 framework preserve the standard user 
interaction with the legacy codes while also providing the ability to use the Internet to exchange data and 
work in collaborative environments. This framework allows the single user to optimize his results from 
within his discipline and then “publish” them for the world to use in their models. The user interface 
consists of a graphical user interface (GUI) to direct a portion of the design process. Shown in Figure 3 is 
the RECIPE® executive GUI. 



Figure 3. RECIPE® Executive GUI 


To determine its effectiveness in saving time and achieve a collaborative environment, a Thermal Analysis 
Test Bed (TATB) was developed that connected only the trajectory analysis, the aeroheating analysis and 
the thermal analysis. The goal of this activity was to demonstrate the effectiveness of the collaborative 
environment and show the time savings attained by eliminating much of the data manipulation performed by 
the users of the programs mentioned. 
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In the TATB, RECIPE®’ will be performing all of the functions that the user would have to perform with the 
exception of “building” the initial analytical models. That function is left to the analyst. Figure 4 is a 
simplified schematic of the TATB analysis process. All of the functions in the boxes are RECIPE® 
functions, while the circles are entry points where the user can assess the calculations of the analysis codes. 
These entry points are not necessary except to ensure that the inputs are being used properly and that the 
engineer has confidence that data being generated are correct. Once an iteration is completed and the TPS 
masses have been calculated, this process may be iterated to approach an optimum design. For example, if 
the masses are excessive and pose a threat to the vehicle feasibility changes may be made. One of these is 
altering the trajectory; another may be selecting a more technologically advanced TPS material. Using the 
previously outlined process, another iteration would likely be too time consuming and labor intensive . But, 
using this collaborative tool much of the labor has been removed making iterations more attractive. So 
several trajectories may be analyzed considering the thermal implications, and several different TPS 
materials may be analyzed to examine the technology implications. 



Review Data 


Figure 4. TATB Simplified 


PROGRAM EXECUTION/TEST CASE 


A sample analysis of an SSTO vehicle TPS was performed to determine the effectiveness of the TATB 
process. The object of this test was to compare the actual time required to complete the analyses described 
earlier. The vehicle uses air-breathing propulsion to help it achieve its mission requirements. As stated 
earlier, this requirement puts a severe burden on the TPS not only during reentry from orbit, but also on 
ascent where the vehicle may accelerate up to speeds 15 times the speed of sound before going to orbit. For 
this test case the computer platforms are a UNIX-based DEC ALPHA (on which MINIVER, SINDA, 
THINDATA and the RECIPE®’ server were run) and an Apple Power Macintosh 9600 (on which the 
RECIPE® client and spreadsheet were run). 
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First a baseline analysis time was established using the process shown in Figure 2. As stated earlier this 
process is very labor intensive and requires considerable interaction from the analysts to manipulate the data 
to be used by the specified tools. Next the process shown in Figure 2 was executed. Figure 3 shows the 
Executive Graphical User Interface (GUI) for RECIPE©. In this Executive GUI under thermal the button 
“Edit Thermal” was selected. Another set of GUI’s is now available. One in which the MINIVER models 
may be set up and edited and another where the SINDA models are set up and edited. 

In the MINIVER GUI the POST trajectory data that will be used is selected. RECIPE® retrieves the 
specified data and executes the thinning program. This program required some interaction from the user to 
determine the degree of thinning required to minimize the data to 50 sets. From this point in the process the 
MINIVER model is set up and run. The engineer is in full control of where and how the data will be 
executed and used. RECIPE© provides model connectivity, file transfer, and data manipulation. In the 
process of running MINIVER, the vehicle is divided in 40 body points, 20 leeward and 20 windward. 
There will be a separate output file of convective heat rates and radiation equilibrium temperature both as 
functions of time. The TATB database enables the correlation of the MINIVER output files with the 
SINDA models of each body point TPS for which these output files will be input. As is shown in Figure 5 
of the MINIVER GUI there is a number of text files that contain the heat rate data for each particular 
project. The database allows the user to store several projects’ output files. The user next selects the 
SINDA GUI. The desired MINIVER output file is selected and the corresponding SINDA model is 
selected. With the MINIVER data edited into the SINDA model program can be executed and the TPS 
thickness for the selected body point can be calculated. Each body point SINDA model is executed until all 
of the TPS thicknesses are calculated. For these test cases the SINDA models of each body point will be 
run in series as the MINIVER data is linked to the SINDA models and the user selects “Run” in the SINDA 
GUI (Figure 6). Later versions of the code will enable the user to link all of the MINIVER output with the 
SINDA models and the models will be run with no user interaction. 

Finally with all of the TPS sized for the whole vehicle the mass is calculated using a spreadsheet. The 
output from each of the SINDA runs is linked directly in the spreadsheet and the vehicle TPS mass is 
calculated based on the area that is represented by the body point and the density of the TPS material. 
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Figure 5. MINIVER GUI 


Figure 6. SINDA GUI 
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RESULTS/COMPARISON 


A benchmark was established by executing the process as described in Figure 2 and measuring the time 
required to complete each step. For this work the process was executed once with no extra iterations. The 
process is now well understood and can be performed more easily now than in the initial runs when the 
process was being developed. The data shown in Table 1 is the amount of time required to complete the 
TPS conceptual analysis of a vehicle before the TATB. The length of time to complete the initial analysis 
was probably 3 to 4 times the values shown in the tables. But as the users became more familiar with the 
tools for data manipulation, the length of time to complete the processes became shorter. 

The results of using the RECIPE 4 code in the first steps of the TATB process shows that there is about a 
20% reduction in the time taken to complete the steps to edit the POST data and to thin it. This reduction is 
due mainly to the decrease in the time required to move and format data for each of the analysis tools . This 
tool does not remove the responsibility of the analysts to utilize the legacy codes, but it enables them to 
integrate the tools to achieve a better set of results more quickly. An even greater reduction in the total time 
to complete the analysis is expected when file management system portion of the code is completed which 
will be used to connect the aeroheating data to the thermal models. A conservative estimate of 50% is the 
anticipated reduction in the analysis cycle time. 



Manual j 

Process Step 

Step Time (min.) 

Cumulative Time (min.) 

iEiiit Trajectory 

13 

13 

Thinning Data 

7 

20 

Executing MINIVER 

7 

27 

Editing MINIVER Output 

7 

34 

Editing SINDA models 

2.5 

36.5 

Executing SINDA models 

3.5 

40 

! 

; Tune To Com plete 40 


527 min.J9. 12 hr. 

Body Points 



Table 1. Time to Complete TPS Analysis Benchmark 


BENEFITS 

The benefits of this type of tool in concept design are numerous. First, because the tool is cross-platform 
the designers may use the type computers with which they are most familiar. The information is easily 
exchanged between disciplines regardless of the platform. The tools will eliminate mistakes in the transfer 
of input and output files. Also several engineers may be accommodated in the collaborative environment. 
Thus better designs may be attained sooner. Design/analysis time will be reduced due to increased 
communication and reduced efforts by the engineers to format the data and pass it on the next user of the 
information. These factors should enable the team to perform more design iterations thereby reaching an 
optimum design. Finally it allows the engineer to concentrate on engineering rather that data manipulation. 
Thus more time can be spent considering the design of the thermal protection system of the vehicle rather 
than developing the models or formatting the data. 

CONCLUSION 

Wurster [4] states that the TPS of the entry vehicle, as much as any other vehicle component, requires 
integrated design at the vehicle system level. The TATB is a demonstration of such a system level tool that 
will allow users to evaluate TPS concepts, trajectories, structure and how they interact and affect the 
feasibility and cost of a SSTO vehicle. It is important to note that this test bed is only a part or module in a 
suite of tools that may be integrated to be used for vehicle design and analysis. Having these integrated 
these tools gives engineers the ability to collaborate on designs and analyses can only make for higher 
fidelity designs and analyses that should eventually lead to better and lower cost designs. It has been shown 
that integrating the tools reduces the amount of time to complete a discipline iteration. This implies that 
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given the original amount of time for analyses more iterations should be completed which help the designers 
optimize a vehicle design. 
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